Despite the publicity on multimedia services which require a point-to-multipoint connectivity, like television streams multicast over Internet Protocol (IPTV), the support of E-Tree services is a recent event in Connection Oriented-Packet Switched (CO-PS) networks, like Multi Protocol Label Switching (MPLS), Transport MPLS (T-MPLS) or Provider Backbone Bridging Engineering (PBB-TE). The debate is still open on how to efficiently support E-Tree services and provide the required network resiliency in CO-PS networks. Some doubt has been instilled that CO-PS networks are not really as good as Connectionless-Packet Switched (CL-PS) networks for such services. Currently, no finalized standard solution exists.
Existing connectionless options like Ethernet-based networks (e.g. Provider Bridge or Provider Backbone Bridge) still rely on very basic control plane solutions for both loop avoidance and resiliency, like the few variants of the Spanning Tree Protocol. Along with their limited capability to implement sophisticated traffic engineering, this is one of the reasons why the move towards CO-PS networks is ineluctably taking place, forcing the standard making bodies and the technical community to face the issues related to the efficient support of E-Tree services.
Ultimately, solutions which completely rely on Layer 3 of the Open Systems Interconnection (OSI) Basic Reference Model (i.e. the IP layer) are unsuitable, cost inefficient and of inappropriate complexity, especially in relation to metropolitan networks.
Standard-making bodies are currently working on a definition of a proper network infrastructure to support E-Tree services with the required degree of efficiency. No complete interoperable solution has been finalized so far for point-to-multipoint infrastructures, but there have been several attempts to solve this problem in CO-PS networks. The most efficient solutions make use of tree infrastructures built in the CO-PS network that connect an ingress or root node (which is a node where the E-Tree service enters the network/sub-network) to the several egress nodes (which are the destinations of the E-Tree service), with the aim of optimizing the overall use of network resources. Extensive literature is available on how to build an optimum tree for a particular network topology and possible constraints. In addition, resiliency is a basic requirement for this kind of service, because revenue generating applications, like IPTV, cannot be delivered to paying customers with poor quality or unacceptable interruptions. This tree infrastructure therefore needs to be protected against link or node failures, possibly in a non-traffic consuming way, like in 1:1 or restoration schemes, where the traffic is sent onto a backup path when the primary path has failed.
A few known solutions address this requirement, with local repair schemes, like Fast ReRoute (FRR) in MPLS, or with global repair schemes whose operation consist in providing a complete backup tree. A limitation of local repair schemes is that in the case of node failure the tree infrastructure needs to be locally modified, because some other node in the network needs to forward the traffic in a different way to make up for the failed node and ensure the E-Tree service traffic continuity. This can be difficult to implement, require a very high degree of complexity and result in a longer recovery time. In addition, traffic duplication is possible during fault conditions. Besides the need to actually configure a potentially very high number of alternative paths in order to avoid issues with single points of failure, the main limitation of FRR lies in its necessarily local repair nature, which is not particularly well suited for a potentially non-trivial tree infrastructure.
In the case of global repair schemes, irrespective of where and what the fault condition is in the active tree infrastructure, all of the traffic related to the E-Tree service is switched to the backup tree. This can be particularly problematic for the egress nodes, since even though the switching time is kept to a minimum, all such nodes will see an impact on the traffic, even those which are remote from where the fault has occurred. To add further complexity to such a scenario, E-Tree specific control plane protocols, like for instance IGMP in case of IPTV, can experience difficulties and may need to recover updated information on the backup tree before allowing the traffic to be forwarded normally again. This can lead to an even longer time for the protection scheme to finally converge and return to normal operation.